Invisible password reset protocol

ABSTRACT

Techniques are disclosed herein for facilitating invisible password reset protocols. More specifically, the techniques described herein eliminate the need for end users to have to periodically change their authentication information (e.g., password information). The mechanisms facilitate automated and invisible modification to a password without active participation by the end user. The mechanisms are made possible through the use of a credential-free or zero password login (ZPL) system. Among other benefits, the automation techniques discussed herein frequently change passwords and thus, reduce the chances that passwords are stolen and/or otherwise misused. As discussed herein, the credential-free or zero password login (ZPL) system also remembers and/or otherwise automatically provides users with authentication information (e.g., credentials) for a registered resource at the time of access time.

RELATED APPLICATIONS

This application is a continuation of, and claims priority to U.S.patent application Ser. No. 15/003,413, filed Jan. 21, 2016, entitled“INVISIBLE PASSWORD RESET PROTOCOL,” which claims the benefit of, andpriority to U.S. Provisional Patent Application No. 62/125,399, filed onJan. 21, 2015, entitled “INVISIBLE PASSWORD RESET PROTOCOL,” which theirhereby incorporated by reference in their entirety.

TECHNICAL BACKGROUND

Aspects of the disclosure are related to computing hardware and softwaretechnology, and more particularly, to techniques for facilitating aninvisible password reset protocol.

TECHNICAL BACKGROUND

Anyone with a suitable Internet appliance, such as a personal computerwith a standard Internet connection, may access (or go on-line) andnavigate web pages stored on Internet-connected servers for the purposeof obtaining information and initiating transactions with hosts of suchservers and pages. Companies offer various subscription servicesaccessible via the Internet. For example, it is common for people tobank, trade stocks, shop, etc., from the comfort of their own homes viaInternet access. Typically, a user, through subscription, has access topersonalized and secure web pages for such functions. By typing in auser name and a password or other personal identification code, a usermay obtain information, initiate transactions, buy stock, and accomplisha myriad of other tasks.

Unfortunately, one problem that is encountered by an individual who hasseveral or many such subscriptions to Internet-brokered services is thatthere are invariably many passwords and/or log-in codes to be used andit is not advisable to utilize the same password or code for everyservice as this poses an increased security risk. Furthermore, usingdifferent login identifiers and passwords for each on-line accountpresents numerous problems; not the least of which is remembering eachlogin identifier and password. This secure access problem also manifestsitself in an enterprise context. For example, employees must regularlyaccess system servers. However, despite the security risks, passwordsand/or other credential information are not regularly modified becausesuch regular changes are often overly burdensome.

Overall, the examples herein of some prior or related systems and theirassociated limitations are intended to be illustrative and notexclusive. Upon reading the following, other limitations of existing orprior systems will become apparent to those of skill in the art.

Overview

Provided herein are systems, methods, techniques and software thatfacilitate invisible password reset protocols. In some embodiments, acloud-based credential management system is disclosed having one or moreprocessors and one or more computer readable storage media with programinstructions stored thereon, which when executed by the one or moreprocessors, cause the one or more processors to perform variousfunctions. In some embodiments, the functions include reconstructing anexisting password required for accessing a user account associated witha protected resource responsive to receiving an indication to modify theexisting password. The functions further include directing a browsersession to access the user account associated with protected resourceusing the existing password and accessing a password reset configurationfile corresponding to the protected resource. The password resetconfiguration file includes a series of operations that, when performedby the browser session, cause the protected resource to reset theexisting password required for accessing the user account. The functionsfurther include directing the browser session to automatically performthe series of operations without active participation from a user.

This Overview is provided to introduce a selection of concepts in asimplified form that are further described below in the TechnicalDisclosure. It may be understood that this Overview is not intended toidentify key features or essential features of the claimed subjectmatter, nor is it intended to be used to limit the scope of the claimedsubject matter.

BRIEF DESCRIPTION OF THE DRAWINGS

Many aspects of the disclosure can be better understood with referenceto the following drawings. While several implementations are describedin connection with these drawings, the disclosure is not limited to theimplementations disclosed herein. On the contrary, the intent is tocover all alternatives, modifications, and equivalents.

FIG. 1 depicts a block diagram illustrating an example environment forfacilitating secure, credential-free user access to resources andautomated password reset, according to some embodiments.

FIGS. 2A-2C depict example components of a credential management (zeropassword login) platform, according to some embodiments.

FIG. 3 depicts a flow diagram illustrating example operation of acredential management (zero password login) platform for providing logincredentials to an access system for zero password login, according tosome embodiments.

FIG. 4 depicts a flow diagram illustrating example operation of abrowser extension for operating with a web browser on an electroniccomputing device, according to some embodiments.

FIG. 5 depicts a sequence diagram illustrating example operation in anexample for facilitating secure, credential-free user access toresources, according to some embodiments.

FIG. 6 depicts a sequence diagram illustrating example operation in anexample for facilitating secure, credential-free user access toresources, according to some embodiments.

FIG. 7 depicts a flow diagram illustrating an example operation fordirecting a browser session to automatically perform a series ofoperations for resetting a password required for accessing a useraccount associated with a protected resource, according to someembodiments.

FIGS. 8A and 8B depict sequence diagrams illustrating example operationsof various devices, systems, and an end users for facilitating aninvisible password reset protocol via a credential management (zeropassword login) platform, according to some embodiments

FIG. 9 illustrates a computing system suitable for implementing any ofthe architectures, components, applications, services, processes, andoperational scenarios disclosed herein with respect to FIGS. 1-8B anddiscussed below in the Technical Disclosure.

TECHNICAL DISCLOSURE

Techniques are disclosed herein for facilitating invisible passwordreset protocols. More specifically, the techniques described hereineliminate the need for end users to have to periodically change theirauthentication information (e.g., password information). The mechanismsfacilitate automated and invisible modification to a password withoutactive participation by the end user. The mechanisms are made possiblethrough the use of a credential-free or zero password login (ZPL)system. Among other benefits, the automation techniques discussed hereinfrequently change passwords and thus, reduce the chances that passwordsare stolen and/or otherwise guessed or misused. As discussed herein, thecredential-free or zero password login (ZPL) system also remembersand/or otherwise automatically provides users with authenticationinformation (e.g., credentials) for a registered resource at the time ofaccess time.

In some embodiments, the system accepts and securely stores registrationinformation for accessing privileged resources during a registrationprocess. The registration information can include identification andauthentication information for each privileged resource. Theauthentication process can also include registration of one or moresecondary authentication devices and that are used to verify theidentity of the end user in lieu of the end user providing credentials.

In some embodiments, various security policies can also be selectedand/or otherwise established during the registration process.Furthermore, multi-factor authentication can be selected and/orotherwise triggered in response to an end-user requesting access to aprotected resource. The multi-factor authentication can provide an enduser with credential-free access to protected resources whilemaintaining an enhanced level of security.

The techniques introduced herein can be embodied as special-purposehardware (e.g., circuitry), as programmable circuitry appropriatelyprogrammed with software and/or firmware, or as a combination ofspecial-purpose and programmable circuitry. Hence, embodiments mayinclude a machine-readable medium having stored thereon instructionswhich may be used to program a computer (or other electronic devices) toperform a process. The machine-readable medium may include, but is notlimited to, floppy diskettes, optical disks, compact disc read-onlymemories (CD-ROMs), magneto-optical disks, read-only memories (ROMs),random access memories (RAMs), erasable programmable read-only memories(EPROMs), electrically erasable programmable read-only memories(EEPROMs), magnetic or optical cards, flash memory, or other type ofmedia/machine-readable medium suitable for storing electronicinstructions.

FIG. 1 depicts a block diagram illustrating an example environment 100for facilitating secure, zero password user access to resources 160 andautomated password reset via a credential management (zero passwordlogin) platform 140, according to some embodiments. More specifically,the example of FIG. 1 illustrates an environment in which end user 105can obtain secure access to the resources 160 without providing usercredentials (or login information) directly to the access system 110(i.e., device which the end user is using to attempt to access theresource). Furthermore, the example of FIG. 1 also illustrates anenvironment in which the end user's 105 password (or other credentials)can be automatically reset without active participation by the end user.

As shown in the example of FIG. 1, environment 100 includes the accesssystem 110, a mobile device 112, a public app store 120 having a ZPL app121 available for download, a credential management (ZPL) platform 140,a database or storage unit 141, various resources 160, and an external(password modification) verification system 170. As shown, and by way ofexample and not limitation, the resources 160 can include web platforms162, enterprise rack servers 164, and cloud services 166. In the exampleof FIG. 1, the access system 110 and the mobile device 112 are under thecontrol of end user 105. A single end user 105, access device 110 andmobile device combination is shown for simplicity; however, the exampleenvironment 100 can include any number of access systems 110 and themobile devices 112 under the control of any number of end users 105.Moreover, although shown as a single entity, it is appreciated that thecredential management (ZPL) platform 140 can be physically and/orfunctionally distributed.

Prior to operation, one or more resources and devices are registeredwith the credential management (ZPL) platform 140. For example, the enduser 105 can register details about a given resource and secondarysecurity device(s), e.g., mobile device 112, with the credentialmanagement (ZPL) platform 140. In some embodiments, the deviceinformation can include contact information for secondary securitydevices such as, for example, a mobile number or IP address of anapplication operating on mobile device 112. Additionally, in someembodiments, an end user directs a secondary security device, e.g.,mobile device 112 to download and installs the ZPL app 121 from thepublic app store 120 on mobile device 112 as part of a registrationprocess with the credential management (ZPL) platform 140.

The registration details include at least some authentication or logincredential information so that the user does not need to maintain(remember) and/or otherwise provide this information when accessing theresource. For example, an end user can provide username and passwordinformation for accessing the end user's Facebook™ account. Moreover, asdiscussed herein, in the enterprise context, system administrators canincrease the frequently in which they modify passwords for heightenedsecurity.

In some embodiments, during the registration process, an end user and/oran administrator can provide password requirement criteria for eachresource. The password requirement criteria can include minimum andmaximum number of allowed characters for a password, the specialcharacters that are allowable/not allowable, the frequency with whichthe password should be modified, etc. The password requirement criteriacan also indicate use of a password verification system 170, e.g., emailplatform where a resource sends password modification verifications. Insome embodiments, the credential management (ZPL) platform 140 canaccess the email for the end client in order to intercept email messagessent by a resource to the end client confirming the reset request. Asdiscussed herein, the credential management (ZPL) platform 140 canautomatically locate the confirmation email sent by the resource andparse the email to obtain a confirmation and/or otherwise take action,e.g., simulate mouse-click, visit page link in the email, etc., toconfirm the email reset. Advantageously, the credential management (ZPL)platform 140 can automatically perform these operations without anyactive participation by the user.

Additionally, the registration process can include selection and/orconfiguration of policies and policy information. The policies caninclude, by way of example, relative device proximity policies,geofencing policies, biometric identification policies, movementpolicies, etc.

The relative device proximity policies can include, for example,directing the mobile device 112 and/or the access system 110 to detectand report on their proximity. In some embodiments, the proximity can bedetermined based on Bluetooth connectivity or a determination as toBluetooth RSSI strength to ascertain a physical distance between themobile device 112 and the access system 110 (e.g., the machine used toattempt to access the resource). In such cases, RSSI strength beinggreater than a threshold can indicate that the mobile device 112 and theaccess system 110 are sufficiently proximate to satisfy the relativedevice proximity policy.

The geofencing policies can include, for example, directing the mobiledevice 112 and/or the access system 110 to detect and report geolocationinformation. In some embodiments, the system may already have thisinformation as part of the request. For example, the geolocationinformation can include the IP address used to access the resource. Inother instances, the policies can be configured to request an IP addressfrom the mobile device as well. In any case, access to the resource isgranted only when the user is within a predetermined geographicallocation or area. If the access systems 110 and/or the mobile device 112is outside that predetermined location or areas, then access is notgranted.

The biometric identification policies can include, for example,directing the mobile device 112 and/or the access system 110 to obtainfingerprint, retina, face, voice or biometric based identificationinformation from the end user 105 and to report the information to thecredential management (ZPL) platform 140.

The movement policies can include, for example, directing the mobiledevice 112 and/or the access system 110 to obtain movement informationfrom the end user 105. The movement can include an air signature suchas, for example, movement of the mouse, or a registered device such asmobile phone 112 to make a signature in the air, including shaking of adevice in a specific manner, etc.

In the various examples discussed herein, authentication information isprimary requested from the mobile device 112 and/or the access system110. It is appreciated that any number of devices (including secondaryauthentication devices) can be registered and the various policesconfigured to direct those devices to obtain and send information to thecredential management (ZPL) platform 140 for authentication.

As discussed herein, authentication polices can be configured forconditional or unconditional multi-factor authentication. For example,as discussed in more detail below, in some embodiments, various score orrisk factors can be used to determine whether multi-factorauthentication is triggered or whether additional factors of themulti-factor authentication should be utilized by the system toauthenticate the user.

Although not illustrated for simplicity, in the example operation ofFIG. 1, the end user 105 has downloaded and installed the ZPL app 121from the public app store 120 onto mobile device 112. Additionally,access system 110 may be configured with a browser extension 111.

FIGS. 2A-2C depict example components of a credential management (zeropassword login) platform 200, according to some embodiments. Thecredential management (zero password login) platform 200 can be thecredential management (zero password login) platform 140 of FIG. 1,although alternative configurations are possible. The functionsrepresented by the components, modules and/or engines described hereincan be implemented individually or in any combination thereof, partiallyor wholly, in hardware, software, or a combination of hardware andsoftware.

As illustrated in the example of FIG. 2A, the credential management(zero password login) platform 140 includes an enterprise administratorinterface 210, a registration engine 220 a policy engine 230, anauthentication engine 240, a notification engine 250, a browserextension (BE) and shell interface 260, one or more servers 270, one ormore data stores 275, and an invisible password reset protocol (IPRP)engine 280. Other systems, databases, and/or components are alsopossible. Some or all of the components can be omitted in someembodiments.

The enterprise administrator interface 210 is configured to interfacewith enterprise administrators in some embodiments. In enterprisesettings, an enterprise administer can provide the credential management(zero password login) platform 200 with various registration and/orpolicy information. For example, the enterprise administrators canconfigure servers, e.g., enterprise rack servers 164, for protectedaccess and/or periodically change passwords for enhanced security.

The registration engine 220 is configured to interface with an end user,administer, or bot to setup and/or update various resource registrationinformation. As discussed here, the credential management (zero passwordlogin) platform 200 facilitates secure access to various resource byproviding the authentication credentials to for, example, a browserextension executing on a web browser of an access device responsive to arequest by an end user and subsequent verification that the end user isin fact who they say they are.

The policy engine 230 is configured to store and present various policyconfiguration options to end users and or system administers. Theauthentication engine 240 is configured to detect and apply thepolicies. A more detailed example of an example authentication engine isshown and discussed in greater detail with reference to FIG. 2B.

The notification engine 250 is configured to generate and providevarious notifications to end users and/or system administrators.Notification can be sent, for example, to access system for display toan end users responsive to protected resource access requests. The BEand shell interface 260 is configured to interact with browserextensions installed on access systems, shell interfaces on accesssystems, and/or any other software modules or programs that areinstalled on access systems that are registered and configured to accessthe credential management (ZPL) platform.

The invisible password reset protocol (IPRP) engine 280 facilitates theinvisible password reset protocols discussed herein. Example componentsof the invisible password reset protocol (IPRP) engine 280 are shown anddiscussed in greater detail with reference to FIG. 2C. Other embodimentsare also possible.

Referring now to FIG. 2B, which depicts example components of theauthentication module 230, according to some embodiments. As illustratedin the example of FIG. 2B, the authentication engine 230 includes ascoring module 232, an authentication (multi-factor) module 234, acrypto & key module 236, and a session joining module 238.

In the example of FIG. 2B, the scoring module 232 is configured tocalculate a security level from the browsing behavior of an end clientby generating a security-level evaluation, which is referred to hereinas a score. By way of example, the score can be in the form of one ormore of: a numerical score, an alphanumeric set of characters, or avisual identifier, such as color, sound, including combinations and/orvariations thereof.

In some embodiments, the score can be used, for example, (a) to revoke asession ID to prevent an end user from accessing a resource, (b) as ananswer to a third party or a resource that may choose to act upon it,(c) to ask the end user to for additional verification using othermeans. The score can be calculated in whole or in part at the credentialmanagement (ZPL) platform 140, the access system 110, and/or the mobiledevice 112, or any other electronic device.

In some embodiments, the system assesses, summarizes and depicts thesecurity level of a browsing session that is allowing an end client toaccess a resource by generating a security-level score. The score can bein the form of a numerical score, an alphanumeric set of characters,and/or a visual identifier, such as color, sound, etc. In someembodiments, the goal of the score is to identify if the browsingbehavior of the person who is accessing the protected resources deviatesfrom the learned experience that has been taught to the system.

In some embodiments, the score can be generated based on any number offactors and can consider various broad categories. By way of example,the score can consider the following broad categories: the browsingbehavior of the end client such as mouse pointer speed, scrolling speed,focus of the actions being performed on a webpage and more; external andhistorical information about how users are using the website; thelikelihood of the end client accessing the resource at the time it isbeing accessed, where it is being accessed from and more; additionalfeatures that aid in the identification and/or classification of an endclient's browsing behavior; etc.

In some embodiments, the score is calculated or generated using amulti-level approach which can be implemented as a hierarchy of modules.In some instances, a separate partial score can generated for each ofthese multiple categories. For example, there can be a module for eachcategory and each module may consist of additional modules assessingspecific aspects. In some embodiments, the system analyzes a site alongmultiple dimensions (i.e., with respect to a plurality of differentwebsite properties). The partial scores can then collected and combinedby an integration module to generate the final score.

In some embodiments, the various techniques discussed herein may beperformed a client side web-browser extension, a proxy, or a computerprogram that runs on an access system or secondary authenticationdevice. The calculation of the score can use one mathematical functionthat incorporates all the indications and information pertinent toverifying the authenticity of the end client's, e.g., access systems,attempt to access the resource.

In some embodiments, the mechanism to calculate the security level of asite is highly customizable allowing the addition or deletion ofparameters and factors, as the technology and business practices evolve.

In some embodiments, the security level of a site, can be represented ina non-limiting way as: (a) a numerical score, (b) an alphanumeric set ofcharacters (e.g., B+), (c) a visual identifier, such as color, (d) asound, (e) a graphical depiction such as a plot, or a set of multipleinstances of all the above. Additionally, the system can generatedetailed reports showing why the security level of a site is as reportedand accompanied by optional tips on how to improve the score. The levelof detail of this information can be defined by a tunable parameter thatranges from the raw output of all the data that the invention processedor it can be aggregated at an easier-to-understand level of granularity.

The authentication (multi-factor) module 234 is configured to provide aconfigurable multi-factor authentication. The multi-factorauthentication is configured such that it is not intrusive, timeconsuming or confusing. The system can provide various multifactorauthentication techniques that may seem invisible yet effective atascertaining the authenticity of the identity of the end client.

The various options include but may not be limited only to (1) BluetoothRSSI strength to ascertain how far physically a mobile or tablet deviceis from a machine used to access the resource (2) Geo-location fencing,based on the IP address used to access the resource, to make sure thataccess to the resource is granted only if the user is in certaingeographical locations or is not granted of the user is in certaingeographical locations. (3) Fingerprint, retina, face, voice orbiometric based identification provided for by the device that is beingused to access the resource or any other device that may have beenregistered as a second factor device by the end client (4) an airsignature—movement of the mouse, or a device like a mobile phone to makea signature in the air, including shaking of a device in a specificmanner and more.

The crypto & key module 236 is configured to securely store credentialsfor the end client, e.g., the access system and/or the end user, in theone or more data stores 275. For security, the stored credentials areencrypted. In some embodiments, the encryption can be accomplishedthrough cryptography where multiple keys are generated and maintained onvarious machines not belonging to the end client.

The session joining module 238 is configured to join multiple sessionsas discussed herein. An example of session joining is shown anddiscussed in greater detail with reference to FIG. 6. In someembodiments the credentials may never be transferred in any way shape orform to the access system. In such instances, only session IDs aretransferred to the device being used. The system can help expire thesession after a specified amount of time as set by the administrator ofthe organization or the end client themselves.

For example, in some embodiments, the cloud store proceeds to providethe end client with a valid session ID whenever they would like to use aprotected resource, by using the stored encrypted credentials and theencryption key of the end client used to store the credentials in thefirst place. This allows for passwords and usernames to never reach theclients computer yet provide a seamless login experience. Furthermorethe system can use various factors to determine of the end client tryingto access the resource is actually the person/end client allowed to doso or not by using various features on their mobile phones, tablets,google glass and other devices.

Referring now to FIG. 2C, which depicts example components of theinvisible password reset protocol (IPRP) engine 280, according to someembodiments. As illustrated in the example of FIG. 2C, the invisiblepassword reset protocol (IPRP) engine 280 includes an invisible passwordreset protocol (IPRP) control module 281, a password reset configurationmodule 284, an automated browser module 288, a password modificationverification access module 289, and a password module 290.

The invisible password reset protocol (IPRP) control module 281 includesa job module 282 and a configuration module 283. The configurationmodule 283 includes cron job configuration information that indicates,for example, the frequency with which passwords should be changed foreach resource, etc. This information can be provided by an administratorwhen invisible password reset protocols are configured by anadministrator for each resource. The job module 282 is configured toexecute a periodic cron job to identify users having correspondingpasswords associated with protected resources that should be changedbased on the configuration information.

The password reset configuration module 284 includes a natural languageprocessing (NLP) module 285, a manual configuration module 286 and oneor more resource configuration data store(s) 287. The one or moreconfiguration data store(s) 287 are configured to store password resetconfiguration files. The password reset configuration module 284generates one or more password reset configuration files for eachprotected resource. Each reset configuration file includes operations orinstructions for resetting a password on a particular resource. Forexample, the reset configuration file can indicate that after logginginto the resource, a particular button should be clicked, a URL visited,etc.

The NLP module 285 is configured to use NLP algorithms based on machinelearning to train the system how to direct the automated browser forresetting a password. The NLP module 285 can parse language, deceiverwhich buttons to click, etc., even when there are various changes on thesite. For example, the NLP algorithm can detect and train that apassword reset button is the same even if it was spatially relocated ona page. The manual configuration module 286 can be used to manuallyteach the system on how to reset a password on each resource.

The automated browser module 288 is configured to direct a browsersession to launch and perform a series of operations for resettingpasswords. The series of operations can include operations to reset thepassword e.g., as determined form a password reset configuration file,as well as instructions for formatting and/or otherwise displaying thebrowser session to the end user if the browser session is launched on anaccess system and at least partially visible to an end user.

As discussed herein, the automated browser module 288 can direct a localbrowser session to launch or a remote browser session launch at anaccess system. In some embodiments, the automated browser module 288 canmake a determination as to where the browser session is launched basedon where or when the access system last accessed the resource (time orfrequency of last access) and/or one or more of requirements of theprotected resource. For example, if an access system has recentlyaccessed the resource from one geographic location or if the accesssystem is currently accessing the resource, then the automated browsermodule 288 might direct reset the password from the access system sothat the resource is not confused by subsequent geographically diverseaccesses. Some resources might be confused with the subsequentgeographically diverse accesses and, for example, lock a user out of theuser account.

As discussed herein, the browser session can open a new browser, aparallel browser session, a browser tab, etc. In some embodiments, thebrowser session is directed or otherwise instructed to execute in thebackground and is invisible to the end user. In other embodiments, thebrowser session is visible to the end user but the operations arenon-transparent. For example, a browser session that is performing theoperations for resetting a password can be blacked out and/or providesome messaging to the user indicating the password is being changed:“OnionID is changing your Amazaon.com password.” In some embodiments,the series of operations performed in the parallel browsing session arenon-transparent to the user.

The password modification verification access module 289 is configuredto interact with an external verification system associated with an enduser to verify that the password should be changes. For example, in someembodiments, the verification access module 289 can retrieve averification code from a verification system and provide theverification code to the resource to confirm reset of the password.

The password module 290 includes a password generation module 291 and apassword configuration module 292. The password configuration module 292is configured to store password reset criteria for each protectedresource. For example, the password reset criteria can include min andmax characters allowed for a password on a particular resource, allowedspecial characters for the password, a desired or required passwordmodification frequency, etc. The password generation module 291 isconfigured to generate random strong passwords based on the passwordreset criteria.

FIG. 3 depicts a flow diagram illustrating an example operation 300 forproviding login credentials to an access system for zero password login,according to some embodiments. The example operation 300 may beperformed in various embodiments by a credential management (zeropassword login) platform such as, for example credential management(zero password login) platform 140 of FIG. 1 or 200 of FIG. 2, one ormore processors, and/or other modules, engines, components or toolsassociated with a credential management (zero password login) platform.

As discussed above, prior to execution of operation 300 it is assumedthat one or more resources have been registered for the end user.

To begin, at step 302, the credential management (zero password login)platform receives a protected resource access request from a resourceaccess system. At step 304, the credential management (zero passwordlogin) platform processes the protected resource access request toidentify a user and a protected resource that the user is attempting toaccess. At step 306, the credential management (zero password login)platform identifies a predetermined authentication policy associatedwith the protected resource.

At step 308, the credential management (zero password login) platformgenerates a request for authentication information based on theauthentication policy. At step 310, the credential management (zeropassword login) platform sends the request for authentication fordelivery to a mobile device associated with the user. At step 312, thecredential management (zero password login) platform receives a responseto the authentication request sent by the mobile device.

At decision step 314, the credential management (zero password login)platform determines whether the authentication policy is satisfied. Ifthe authentication policy is satisfied then, at step 316, the credentialmanagement (zero password login) platform accesses the login credentialsassociated with the protected resource. At step 318, the credentialmanagement (zero password login) platform generates a response to theprotected resource access request that includes the login credentials.

FIG. 4 depicts a flow diagram illustrating an example operation 400 of abrowser extension for operating with a web browser on an electroniccomputing device, according to some embodiments. The example operation400 may be performed in various embodiments by an access device and,more particularly, a browser extension operating with a web browser onthe access device such as, for example, browser extension 111 operatingon access system 110 of FIG. 1.

As discussed above, prior to execution of example operation 400 it isassumed that one or more resources have been registered for the enduser.

To begin, at step 402, the browser extension monitors user resourceaccess attempts. At decision step 404, the browser extension detectswhether a user resource access attempt is detected. If a user resourceaccess attempt is detected, at decision step 406, the browser extensiondetermine if the resource is protected. However, if a user resourceaccess attempt is not detected, the browser extension returns tomonitoring step 402.

If the resource is protected, at step 410, the browser extensiongenerates a protected resource access request. At step 412, the browserextension receives login credentials. Lastly, at step 414, the browserextension populates the login form with the received login credentialswithout saving the login credentials to system memory. Because the logincredentials are not saved system memory, the credentials are no longerpresent or accessible via the access system once the credentials havebeen submitted to the resource for access.

FIG. 5 depicts a sequence diagram illustrating example operation ofvarious devices, systems, and an end users for facilitating secure, zeropassword user access to resources via credential management (zeropassword login) platform, according to some embodiments. Morespecifically, FIG. 5 illustrates a scenario in which an end user isattempting to gain credential-free access to privileged resource 560 viaa credential management (ZPL) platform 540. The privileged resource 560and the secondary authentication device, i.e., the mobile device 512,have been previously registered with the credential management (ZPL)platform 540.

The example of FIG. 5 includes a secondary authentication device (mobiledevice 512 having a ZPL application installed thereon), an access systemwith a browser extension 510, an administrator system 530, a credentialmanagement (zero password login) platform 540 with data store 541, and aresource 560. Initially, at step 1, the end user attempts to access theresource. For example, the end user may open a web browser and enter theURL www.Facebook.com to access the user's Facebook™ account. At step 2,the browser extension executing on the web browser detects thatFacebook™ is a privileged resource. The browser extension can detectthat the resource is a privileged resource by, for example, looking up ahash value stored inside the browser locally. At step 3, the browserextension responsively generates and sends a protected resource accessrequest to the credential management (ZPL) platform 540.

At step 4, the credential management (ZPL) platform 540 processes theprotected resource access request to identify a predeterminedauthentication policy corresponding to the privileged resource andvarious end user information for verifying the identity of the end user.For example, the end user information can include information about asecondary authentication device i.e., the mobile device 512. Optionally,at step 5A, the credential management (ZPL) platform 540 responsivelygenerates and sends a notification message to the access system. Thenotification message can be displayed by the access system to the enduser and indicate a variety of information. For example, thenotification might identify the policy or policies associated with theresource and provide the end user with status information regarding theauthentication “Facebook™ is on policy 1: Geofencing. We are currentlyverifying that you are located in the predetermined geofence area.” Itis appreciated that more or less information can be provided to the endusers.

Once the secondary authentication device (mobile device 512) isidentified, at step 5B, the credential management (ZPL) platform 540generates and sends an authentication information request to thesecondary authentication device (mobile device 512). The authenticationinformation request indicates additional information to be obtained bythe secondary authentication device. As discussed above, the additionalinformation that is requested can be determined by the policy orpolicies that are preconfigured for accessing the resource during theregistration process. By way of example, the additional information caninclude relative device proximity information, geolocation information(e.g., GPS or IP information), biometric information, device movementinformation, PIN information, etc. Although a single request forinformation is shown, it is appreciated that the credential management(ZPL) platform 540 may request additional information more than oncedepending on the policy and/or the information obtained in theauthentication information responses.

In some embodiments, the ZPL application running on the mobile deviceprocesses the authentication information request and, at step 6, obtainsthe requested information. As discussed, in some instances, the mobiledevice, at step 6A, can request that the user provide some input, e.g.,movements, fingerprint, retinal scan, etc. Once the requestedinformation is obtained, at step 7, the mobile device 512 generates andsends an authentication information response to the credentialmanagement (ZPL) platform 540. At step 8, the credential management(ZPL) platform 540 processes the response to determine whether thepolicy is satisfies. If so, at step 9, the credential management (ZPL)platform 540 accesses the credentials from the data store 541. In someembodiments, the credentials might need to be decrypted at thecredential management (ZPL) platform 540 and/or the access system 510.

At step 10, the credential management (ZPL) platform 540 provides thecredentials to the access system 510 and, more particularly, the browserextension operating with a web browser on the access system 510. At step11, the browser extension populates the webpage or other login form withthe credentials but does not otherwise store the credentials. At step12, the access system 510 provides the credentials and/or otherwisesubmits the login form to the resource and, at step 13, resource accessis established. Once submitted, the credentials are no longer availableor stored on the access system 510.

Although not shown, in some embodiments, the credential management (ZPL)platform 540 can alternatively log into Facebook on behalf of the userand provide session information to the browser extension. For example,the credential management (ZPL) platform 540 can provide a php sessionID to the browser extension. The browser extension can subsequentlyrefresh the page with the session ID to then establish the resourceaccess.

FIG. 6 depicts a sequence diagram illustrating example operation ofvarious devices, systems, and an end users for facilitating secure, zeropassword user access to resources via credential management (zeropassword login) platform, according to some embodiments. Morespecifically, FIG. 6 illustrates a scenario in which an end user(employee) is attempting to gain credential-free access to an enterprisesystem (resource such as, for example, enterprise rack servers 164.

Like FIG. 5, the example of FIG. 6 includes a secondary authenticationdevice (mobile device 612 having a ZPL application installed thereon),an access system with a browser extension 610, an administrator system630, a credential management (zero password login) platform 640 withdata store 641, and a resource 660. Initially, at step 1, the end user(employee) attempts to access the resource. For example, the end usermay open a CLI shell and attempt to login to a server by typing an sshcommand. At step 2, the SSH looks up the SSH-keys stored in the .sshdirectory on the system and creates a fingerprint indicating that theend user (employee) is trying to connect to resource 660 (server). Inthe example of FIG. 6, the SSH key that is stored in the .ssh directoryis a modified SSH key that points to the credential management (ZPL)platform 640. The modified SSH key is used to obtain the actual SSH keyat the credential management (ZPL) platform 540.

At step 3, a protected resource access request is generated and sent tothe credential management (ZPL) platform 540. The protected resourceaccess request includes the modified SSH key. At step 4, the credentialmanagement (ZPL) platform 640 processes the protected resource accessrequest to identify a predetermined authentication policy correspondingto the privileged resource and various end user information forverifying the identity of the end user. For example, the end userinformation can include information about a secondary authenticationdevice, i.e., the mobile device 612. At step 4A, a secure session isestablished between the access system 610 and the credential management(ZPL) platform 640. Optionally, at step 5A, the credential management(ZPL) platform 640 responsively generates and sends a notificationmessage to the access system. The notification message can be displayedby the access system to the end user and indicate a variety ofinformation.

Once the secondary authentication device (mobile device 562) isidentified, at step 5B, the credential management (ZPL) platform 640generates and sends an authentication information request to thesecondary authentication device (mobile device 612). The authenticationinformation request indicates additional information to be obtained bythe secondary authentication device. As discussed above, the additionalinformation that is requested can be determined by the policy orpolicies that are preconfigured for accessing the resource during theregistration process. By way of example, the additional information caninclude relative device proximity information, geolocation information(e.g., GPS or IP information), biometric information, device movementinformation, PIN information, etc. Although a single request forinformation is shown, it is appreciated that the credential management(ZPL) platform 640 may request additional information more than oncedepending on the policy and/or the information obtained in theauthentication information responses.

In some embodiments, the ZPL application running on the mobile deviceprocesses the authentication information request and, at step 6, obtainsthe requested information. As discussed, in some instances, the mobiledevice, at step 6A, can request that the user provide some input, e.g.,movements, fingerprint, retinal scan, etc. Once the requestedinformation is obtained, at step 7, the mobile device 612 generates andsends an authentication information response to the credentialmanagement (ZPL) platform 640. At step 8, the credential management(ZPL) platform 640 processes the response to determine whether thepolicy is satisfies. If so, at step 9, the credential management (ZPL)platform 640 accesses the SSH key from the data store 641. In someembodiments, the SSH key might need to be decrypted at the credentialmanagement (ZPL) platform 640.

At step 10, the credential management (ZPL) platform 640 provides theSSH key to the resource 660 and, at step 10A establishes a securesession between the credential management (ZPL) platform 640 and theresource 660. At step 11, the sessions are joined resulting in resourceaccess.

FIG. 7 depicts a flow diagram illustrating an example operation 700 fordirecting a browser session to automatically perform a series ofoperations for resetting a password required for accessing a useraccount associated with a protected resource, according to someembodiments. The example operation 700 may be performed in variousembodiments by a credential management (zero password login) platformsuch as, for example credential management (zero password login)platform 140 of FIG. 1 or 200 of FIG. 2, one or more processors, and/orother modules, engines, components or tools associated with a credentialmanagement (zero password login) platform.

To begin, at step 702, the credential management (zero password login)platform executes a cron job to identify one or more users havingpasswords associated with resources that need to be reset. Morespecifically, the passwords that need to be reset are for accessingcorresponding user accounts on a protected resource. In someembodiments, the cron job can be run daily for all protected resources.In other embodiments, cron jobs can be configured to run individuallyfor users of each resource at any frequency as determined by anadministrator during configuration of password reset criteria.

At step 704, the credential management (zero password login) platformreconstructs an existing password required for accessing a user accountassociated with a protected resource. The user may be one of the one ormore users having passwords associated with resources that need to bereset. At step 706, the passwords associated with resources that need tobe reset accesses a password reset configuration file corresponding tothe protected resource.

At step 708, the credential management (zero password login) platformdirects launch of a browser session. As discussed herein, the credentialmanagement (zero password login) platform can direct an access system tolaunch a browser session (see FIG. 8A) or, alternatively, can launch thebrowser session itself (see FIG. 8B). Regardless, at step 710, thecredential management (zero password login) platform directs the browsersession to perform a series of operations for resetting the password.

At step 712, the credential management (zero password login) platformretrieves a verification code from a verification system and providesthe verification code to the resource to confirm reset of the password.As discussed above, the password requirement criteria can indicate useof a password verification system such as, for example, an emailplatform where the resource sends a password modification verificationor confirmation. In some embodiments, the credential management (zeropassword login) platform can access the email for the end client inorder to intercept email messages sent by a resource to the end clientconfirming the reset request. For example, the credential management(zero password login) platform can automatically locate the confirmationemail sent by the resource and parse the email to obtain a confirmationand/or otherwise take action (simulate mouse-click, visit page link inthe email, etc.) to confirm the email reset.

FIGS. 8A and 8B depict sequence diagrams illustrating example operationsof various devices, systems, and an end users for facilitating aninvisible password reset protocol via a credential management (zeropassword login) platform, according to some embodiments. Morespecifically, the examples of FIGS. 8A and 8B illustrate scenarios inwhich the credential management (ZPL) platform 840 directs an automatedbrowser session or tab on an access system to perform a series ofoperations for resetting a password required for accessing the protectedresource 860 and an example scenario in which the credential management(ZPL) platform 840 itself launches an automated browser session or tabto perform a series of operations for resetting a password required foraccessing the protected resource 860, respectively.

The examples of FIGS. 8A and 8B include an access system 810, anadministrator system 830, a credential management (zero password login)platform 840 with data store 841, a protected resource 860, and averification system 870. The access system 810, administrator system830, credential management (zero password login) platform 840 with datastore 841, protected resource 860, and verification system 870 may beaccess system 110, administrator system 130, credential management (zeropassword login) platform 140 with data store 141, protected resource160, and verification system 170, respectively, although alternativeconfigurations are possible.

In the examples of FIGS. 8A and 8B, the protected resource 860 has beenpreviously registered with the credential management (ZPL) platform 840.Referring first to FIG. 8A which illustrates an example scenario inwhich the credential management (ZPL) platform 840 directs an automatedbrowser session or tab on an access system to perform a series ofoperations for resetting a password required for accessing the protectedresource 860, according to some embodiments.

Initially, at step 1, an administrator configures the credentialmanagement (ZPL) platform 840 with password reset criteria for protectedresource 860. At step 2, the credential management (ZPL) platform 840detects that a password needs to be modified for a particular useraccount on a particular resource. As discussed herein, a job can be runperiodically to determine which passwords need to be updated. At step 3,the credential management (ZPL) platform 840 accesses a configurationfile corresponding to the resource. At step 4, the credential management(ZPL) platform 840 reconstructs the user's existing password foraccessing the resource. At step 5, the credential management (ZPL)platform 840 determines that the access system should launch theautomated browser session.

To ensure that the access system is online, the credential management(ZPL) platform 840 can wait for the next access request from the accesssystem by the end user. In this example, at step 7, the end userestablishes access to the resource in a manner similar to the resourceaccess discussed with reference to FIG. 5 or FIG. 6. At step 8, thecredential management (ZPL) platform 840 directs the access system tolaunch the automated browser session. In this example, the browsersession is launched in parallel as the access system has already gainedaccess to the resource at step 7. At step 8 a, the access systemlaunches the browser session and, at step 9, the credential management(ZPL) platform 840 directs the browser session to perform a series ofoperations for resetting the password as discussed herein. At step 10,the credential management (ZPL) platform 840 performs the operations onthe resource.

At step 11, the resource optionally sends a verification email to theverification system, e.g., email client of the end user. At step 12, thecredential management (ZPL) platform 840 accesses the verification codeand, at step 13, provides the code to the resource to confirm that theend user wants to change the existing password for accessing theresource. Lastly, at step 14, the password is reset.

FIG. 8B is similar to FIG. 8A, but instead of launching the browsersession from the access system, the credential management (ZPL) platform840 directs an automated browser session or tab to be launched from thecredential management (ZPL) platform.

Steps 1-5 are the same in the examples of FIGS. 8A and 8B. In theexample of FIG. 8B, at step 5, the credential management (ZPL) platform840 determines that the automated browser session can be launched fromthe credential management (ZPL) platform 840 and, at step 6, thecredential management (ZPL) platform 840 launches the browser session.At step 7, the credential management (ZPL) platform 840 directs thebrowser session to perform operations for resetting the password asdiscussed herein. At step 8, the resource optionally sends averification email to the verification system, e.g., email client of theend user. At step 9, the credential management (ZPL) platform 840accesses the verification code and, at step 10, provides the code to theresource to confirm that the end user wants to change the existingpassword for accessing the resource. Lastly, at step 11, the password isreset.

FIG. 9 illustrates computing system 901 that is representative of anysystem or collection of systems in which the various operationalarchitectures, scenarios, and processes disclosed herein may beimplemented. Examples of computing system 901 include, but are notlimited to, smart phones, laptop computers, tablet computers, desktopcomputers, hybrid computers, gaming machines, virtual machines, smarttelevisions, smart watches and other wearable devices, as well as anyvariation or combination thereof. In other examples, other types ofcomputers may be involved in the processes, including server computers,rack servers, web servers, cloud computing platforms, and data centerequipment, as well as any other type of physical or virtual servermachine, and any variation or combination thereof.

Computing system 901 may be implemented as a single apparatus, system,or device or may be implemented in a distributed manner as multipleapparatuses, systems, or devices. Computing system 901 includes, but isnot limited to, processing system 902, storage system 903, software 905,communication interface system 907, and user interface system 909.Processing system 902 is operatively coupled with storage system 903,communication interface system 907, and user interface system 909.

Processing system 902 loads and executes software 905 from storagesystem 503. Software 905 can include a various example processes, whichare representative of the processes discussed with respect to thepreceding FIGS. 1-8B. When executed by processing system 902 tofacilitate secure credential-free user access to resources, software 905directs processing system 902 to operate as described herein for atleast the various processes, operational scenarios, and sequencesdiscussed in the foregoing implementations. Computing system 901 mayoptionally include additional devices, features, or functionality notdiscussed for purposes of brevity.

Referring still to FIG. 9, processing system 902 may comprise amicro-processor and other circuitry that retrieves and executes software905 from storage system 903. Processing system 902 may be implementedwithin a single processing device, but may also be distributed acrossmultiple processing devices or sub-systems that cooperate in executingprogram instructions. Examples of processing system 902 include generalpurpose central processing units, application specific processors, andlogic devices, as well as any other type of processing device,combinations, or variations thereof.

Storage system 903 may comprise any computer readable storage mediareadable by processing system 902 and capable of storing software 905.Storage system 903 may include volatile and nonvolatile, removable andnon-removable media implemented in any method or technology for storageof information, such as computer readable instructions, data structures,program modules, or other data. Examples of storage media include randomaccess memory, read only memory, magnetic disks, optical disks, flashmemory, virtual memory and non-virtual memory, magnetic cassettes,magnetic tape, magnetic disk storage or other magnetic storage devices,or any other suitable storage media. In no case is the computer readablestorage media a propagated signal.

In addition to computer readable storage media, in some implementationsstorage system 903 may also include computer readable communicationmedia over which at least some of software 905 may be communicatedinternally or externally. Storage system 903 may be implemented as asingle storage device, but may also be implemented across multiplestorage devices or sub-systems co-located or distributed relative toeach other. Storage system 903 may comprise additional elements, such asa controller, capable of communicating with processing system 902 orpossibly other systems.

Software 905 may be implemented in program instructions and among otherfunctions may, when executed by processing system 902, direct processingsystem 902 to operate as described with respect to the variousoperational scenarios, sequences, and processes illustrated herein. Forexample, software 905 may include program instructions for implementingenhanced callback operations and related functionality.

In particular, the program instructions may include various componentsor modules that cooperate or otherwise interact to carry out the variousprocesses and operational scenarios described herein. The variouscomponents or modules may be embodied in compiled or interpretedinstructions, or in some other variation or combination of instructions.The various components or modules may be executed in a synchronous orasynchronous manner, serially or in parallel, in a single threadedenvironment or multi-threaded, or in accordance with any other suitableexecution paradigm, variation, or combination thereof. Software 905 mayinclude additional processes, programs, or components, such as operatingsystem software or other application software, in addition to or thatinclude callback process 906. Software 905 may also comprise firmware orsome other form of machine-readable processing instructions executableby processing system 902.

In general, software 905 may, when loaded into processing system 902 andexecuted, transform a suitable apparatus, system, or device (of whichcomputing system 901 is representative) overall from a general-purposecomputing system into a special-purpose computing system customized tofacilitate enhanced callback operations. Indeed, encoding software 905on storage system 903 may transform the physical structure of storagesystem 903. The specific transformation of the physical structure maydepend on various factors in different implementations of thisdescription. Examples of such factors may include, but are not limitedto, the technology used to implement the storage media of storage system903 and whether the computer-storage media are characterized as primaryor secondary storage, as well as other factors.

For example, if the computer readable storage media are implemented assemiconductor-based memory, software 905 may transform the physicalstate of the semiconductor memory when the program instructions areencoded therein, such as by transforming the state of transistors,capacitors, or other discrete circuit elements constituting thesemiconductor memory. A similar transformation may occur with respect tomagnetic or optical media. Other transformations of physical media arepossible without departing from the scope of the present description,with the foregoing examples provided only to facilitate the presentdiscussion.

It may be understood that computing system 901 is generally intended torepresent a computing system or systems on which software 905 may bedeployed and executed in order to implement enhanced callbackoperations. However, computing system 901 may also be suitable as anycomputing system on which software 905 may be staged and from where itmay be distributed, transported, downloaded, or otherwise provided toyet another computing system for deployment and execution, or yetadditional distribution.

Communication interface system 907 may include communication connectionsand devices that allow for communication with other computing systems(not shown) over communication networks (not shown). Examples ofconnections and devices that together allow for inter-systemcommunication may include network interface cards, antennas, poweramplifiers, RF circuitry, transceivers, and other communicationcircuitry. The connections and devices may communicate overcommunication media to exchange communications with other computingsystems or networks of systems, such as metal, glass, air, or any othersuitable communication media. The aforementioned media, connections, anddevices are well known and need not be discussed at length here.

User interface system 909 may include a keyboard, a mouse, a voice inputdevice, a touch input device for receiving a touch gesture from a user,a motion input device for detecting non-touch gestures and other motionsby a user, and other comparable input devices and associated processingelements capable of receiving user input from a user. Output devicessuch as a display, speakers, haptic devices, and other types of outputdevices may also be included in user interface system 909. In somecases, the input and output devices may be combined in a single device,such as a display capable of displaying images and receiving touchgestures. The aforementioned user input and output devices are wellknown in the art and need not be discussed at length here.

User interface system 909 may also include associated user interfacesoftware executable by processing system 902 in support of the varioususer input and output devices discussed above. Separately or inconjunction with each other and other hardware and software elements,the user interface software and user interface devices may support agraphical user interface, a natural user interface, or any other type ofuser interface.

Communication between computing system 901 and other computing systems(not shown), may occur over a communication network or networks and inaccordance with various communication protocols, combinations ofprotocols, or variations thereof. Examples include intranets, internets,the Internet, local area networks, wide area networks, wirelessnetworks, wired networks, virtual networks, software defined networks,data center buses, computing backplanes, or any other type of network,combination of network, or variation thereof. The aforementionedcommunication networks and protocols are well known and need not bediscussed at length here. However, some communication protocols that maybe used include, but are not limited to, the Internet protocol (IP,IPv4, IPv6, etc.), the transfer control protocol (TCP), and the userdatagram protocol (UDP), as well as any other suitable communicationprotocol, variation, or combination thereof.

In any of the aforementioned examples in which data, content, or anyother type of information is exchanged, the exchange of information mayoccur in accordance with any of a variety of protocols, including FTP(file transfer protocol), HTTP (hypertext transfer protocol), REST(representational state transfer), WebSocket, DOM (Document ObjectModel), HTML (hypertext markup language), CSS (cascading style sheets),HTML5, XML (extensible markup language), JavaScript, JSON (JavaScriptObject Notation), and AJAX (Asynchronous JavaScript and XML), as well asany other suitable protocol, variation, or combination thereof.

The functional block diagrams, operational scenarios and sequences, andflow diagrams provided in the Figures are representative of exemplarysystems, environments, and methodologies for performing novel aspects ofthe disclosure. While, for purposes of simplicity of explanation,methods included herein may be in the form of a functional diagram,operational scenario or sequence, or flow diagram, and may be describedas a series of acts, it is to be understood and appreciated that themethods are not limited by the order of acts, as some acts may, inaccordance therewith, occur in a different order and/or concurrentlywith other acts from that shown and described herein. For example, thoseskilled in the art will understand and appreciate that a method couldalternatively be represented as a series of interrelated states orevents, such as in a state diagram. Moreover, not all acts illustratedin a methodology may be required for a novel implementation.

The descriptions and figures included herein depict specificimplementations to teach those skilled in the art how to make and usethe best option. For the purpose of teaching inventive principles, someconventional aspects have been simplified or omitted. Those skilled inthe art will appreciate variations from these implementations that fallwithin the scope of the invention. Those skilled in the art will alsoappreciate that the features described above can be combined in variousways to form multiple implementations. As a result, the invention is notlimited to the specific implementations described above, but only by theclaims and their equivalents.

1-20. (canceled)
 21. A method of resetting an existing password requiredfor accessing a user account associated with a protected resource, themethod comprising: detecting an indication to modify the existingpassword, wherein the existing password is required for accessing theprotected resource; upon detecting the indication, reconstructing theexisting password; determining a location in which to launch a browsersession; launching a browser session in the location; directing thebrowser session to perform a series of operations for resetting theexisting password according to a password reset configuration fileassociated with the protected resource; and resetting the existingpassword.
 22. The method of claim 21, further comprising, in anadministration system, configuring a password reset protocol.
 23. Themethod of claim 22, further comprising, running a cron job to determinewhether a password needs to be updated.
 24. The method of claim 21,further comprising, upon determining a location in which to launch thebrowser session, waiting for a next access request from an accesssystem, wherein a user establishes access to the protected resource. 25.The method of claim 21, further comprising, upon performing a series ofoperations for resetting the existing password, sending a verificationcode to a verification system.
 26. The method of claim 25, furthercomprising, accessing the verification code and providing theverification code to the protected resource.
 27. The method of claim 21,wherein the location is a protected resource access system.
 28. Themethod of claim 21, wherein the browser session is a tab in an existingbrowser session.
 29. A credential management apparatus comprising: oneor more non-transitory computer readable storage media; one or moreprocessors coupled to the one or more non-transitory computer readablemedia; and program instructions stored on the computer readable media,wherein the program instructions direct the one or more processors to:detect a password modification request for a password associated with aprotected resource; access a configuration file associated with theprotected resource; in response to detecting the password modificationrequest, reconstruct an existing password for accessing the protectedresource; determine whether a browser system can be launched; upondetermining the browser session can be launched, launch the browsersession; direct the browser session to perform a series of operationsfor resetting the password; access a verification code, wherein theverification code is provided to a verification system by the protectedresource upon the browser session performing the series of operationsfor resetting the password; and provide the verification code to theprotected resource to reset the password.
 30. The credential managementapparatus of claim 29, wherein upon determining the browser session canbe launched, the program instructions direct a protected resource accesssystem to launch the browser session.
 31. The credential managementapparatus of claim 29, wherein upon determining the browser session canbe launched, the program instructions direct the one or more processorsto launch the browser session in the credential management apparatus.32. The credential management apparatus of claim 29, wherein upondetermining the browser session can be launched, the programinstructions direct the one or more processors to launch the browsersession as a browser tab in an existing browser session.
 33. Thecredential management apparatus of claim 29, wherein the programinstructions further direct the one or more processors to run a cron jobto identify if a password needs to be modified.
 34. The credentialmanagement apparatus of claim 29, wherein the verification code is sentin an email to the verification system.
 35. The credential managementapparatus of claim 34, wherein the verification system is the emailclient of a user.
 36. A method comprising: detecting a request to modifya password for accessing a protected resource; monitoring for anoccurrence of a request to access the protected resource initiated by anaccess system; in response to the request to access the protectedresource, directing the access system to launch a browser session; anddirecting the browser session to perform a series of operations tomodify the password for accessing the protected resource.
 37. The methodof claim 36, further comprising verifying modifying the password througha verification system.
 38. The method of claim 37, wherein verifyingmodifying the password comprises retrieving a verification code from theverification system and providing the code to the protected resource.39. The method of claim 36, further comprising accessing a configurationfile, wherein the configuration file contains information related tomodifying the password of the protected resource.
 40. The method ofclaim 36, wherein the request to modify the password is based on runninga cron job to determine whether a password needs to be updated.